Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Support for Development Cocoapods #91

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sanju-naik
Copy link

At present the plugin doesn't support Development Pods, it raises an Error.

This MR adds support for Development Pods by creating a symlink to the Local Pod directory and placing it inside the Pods/ directory this way it behaves the same as other Pods.

The approach is based on the suggestions offered in the error message raised earlier.

@mattrobmattrob
Copy link

I don't feel incredibly strongly but I think it'd be nice for this functionality to not be part of this plugin.

For example, I've used this in the past to store "development" pods (these were really just custom podspecs stored in the workspace/repo) in the workspace/repo and referenced in the Podfile in the standard way and it worked fine.

Can you do that instead? Either via git submodules or your own symlinks.

@sanju-naik
Copy link
Author

I am trying to achieve what the Cocoapods + Xcode build system does by default because the audience here are, folks who don't know much about Bazel.

For example, I've used this in the past to store "development" pods (these were really just custom podspecs stored in the workspace/repo) in the workspace/repo and referenced in the Podfile in the standard way and it worked fine.

To do this I think we need to manually create a symlink to local pod spec, etc? instead wouldn't it be nice if the plugin handles this and things work out of the box? OR do you see any potential downsides to having this in the plugin?

As I explained above our developers are not used to Bazel yet, so we are trying to match default Xcode + Cocoapods behavior otherwise we need to document this flow which might create some unnecessary confusions.

@mattrobmattrob
Copy link

My critique is mostly that this plugin has a very narrow focus right now. Something like "Write BUILD files for CocoaPods" and you're expanding it to creating/deleting symlinks that are an implementation detail of your dev pod workflow that could be fixed by having people store the dev pods in the workspace and using .gitignore (or however you store files) to ignore the folder that contains them. Then this plugin would work without changes.

@thiagohmcruz
Copy link
Contributor

+1 to not expand the scope of what this plugin solves, IMO we should keep it simple so folks can include in their workflow as one piece of infra that can be composed with other custom/internal ones. If we start adding functionality "just because we can" we might end up with undesired/unnecessary maintenance burden long term.

@sanju-naik
Copy link
Author

Ok understood, cool makes sense, thanks for the explanations 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants